1 00:00:00,660 --> 00:00:01,920 Selamat datang kembali di video lainnya. 2 00:00:02,100 --> 00:00:05,580 Dalam video ini, kita akan membahas tentang kebijakan asal yang sama. 3 00:00:06,660 --> 00:00:14,280 Browser seringkali dijadikan klaim untuk mengakses aplikasi, namun kenyataannya browser adalah salah satunya 4 00:00:14,280 --> 00:00:20,490 program perangkat lunak paling rumit dalam kebijakan asal SIM langsung Anda, salah satu fitur yang banyak 5 00:00:20,490 --> 00:00:24,390 dukungan browser untuk melindungi pengguna dari berbagai serangan. 6 00:00:25,020 --> 00:00:31,710 Sebelum kita membahas tentang kebijakan asal SIM, ada baiknya kita memahami apa itu asal usul. 7 00:00:32,520 --> 00:00:38,970 Ketika konten dimuat dari sumber berbeda di Web, browser harus dapat membedakannya 8 00:00:38,970 --> 00:00:41,190 antara konten dari sumber yang berbeda. 9 00:00:42,030 --> 00:00:44,310 Di sinilah asal usul muncul. 10 00:00:44,850 --> 00:00:52,890 Asal digunakan untuk mendefinisikan pihak-pihak yang berbeda dan menarik batasan di antara mereka dengan lebih tepat, dan ini 11 00:00:52,890 --> 00:00:56,250 asal direpresentasikan sebagai host uap. 12 00:00:56,250 --> 00:01:03,900 Skema portabel mengacu pada protokol yang digunakan, misalnya PDB-nya atau kebencian heterogen yang kita miliki 13 00:01:03,900 --> 00:01:05,460 hampir selalu melihat. 14 00:01:06,240 --> 00:01:12,520 Dan host mengacu pada nama domain dan port mengacu pada port yang tidak dikonfigurasi di web. 15 00:01:12,540 --> 00:01:19,110 Jadi jika Anda melihat contoh yang ditampilkan di layar di sini, ada dua domain yang dipertimbangkan 16 00:01:19,110 --> 00:01:21,210 berasal dari asal yang berbeda. 17 00:01:21,540 --> 00:01:29,040 Alasannya di domain pertama skemanya adalah Hedgepeth, dan di domain kedua skemanya 18 00:01:29,040 --> 00:01:30,500 adalah heterodoksi. 19 00:01:30,990 --> 00:01:34,320 Itu salah satu pembeda kalau skemanya berbeda. 20 00:01:34,620 --> 00:01:37,740 Kedua domain ini berasal dari dua asal yang berbeda. 21 00:01:38,250 --> 00:01:40,530 Demikian pula, kita dapat memeriksa hostnya. 22 00:01:41,040 --> 00:01:44,610 Host di domain pertama adalah dot com yang sah. 23 00:01:45,300 --> 00:01:47,640 Dalam kasus domain kedua, itu jahat. 24 00:01:47,640 --> 00:01:52,500 Dot com, dot com kecil, dan bahkan dot com adalah dua domain yang berbeda. 25 00:01:52,860 --> 00:01:56,850 Dan ada dua domain ini berasal dari asal yang berbeda. 26 00:01:57,300 --> 00:02:04,380 Demikian pula, port dalam kasus pertama adalah ForFour tiga secara default karena kita menggunakan IDP dan in 27 00:02:04,380 --> 00:02:08,010 kasus domain kedua portnya adalah delapan nol delapan nol. 28 00:02:08,430 --> 00:02:14,760 Sekali lagi, port ini dapat digunakan untuk menentukan apakah kedua domain ini berasal dari asal yang sama atau tidak. 29 00:02:15,420 --> 00:02:20,910 Ingat, cukuplah salah satu dari ketiganya berbeda dalam dua domain ini. 30 00:02:21,210 --> 00:02:28,320 Misalnya, Heggarty dapat dot com delapan nol delapan nol adalah satu domain dan Heggarty menjadi jahat. 31 00:02:28,320 --> 00:02:31,770 Dot com delapan nol delapan sembilan adalah domain lain. 32 00:02:32,160 --> 00:02:38,550 Karena nomor port di kedua domain ini berbeda, maka keduanya tetap dianggap berasal dari berbeda 33 00:02:38,550 --> 00:02:39,260 asal. 34 00:02:39,750 --> 00:02:42,150 Jadi begitulah asal mula didefinisikan. 35 00:02:42,750 --> 00:02:49,290 Komunikasi antara asal-usul yang berbeda ini umumnya dikenal sebagai interaksi lintas asal. 36 00:02:49,980 --> 00:02:55,650 Meskipun pandangan juling dan interaksi bermanfaat, hal tersebut juga merupakan penyebab beberapa kerugian. 37 00:02:56,550 --> 00:03:02,760 Beberapa permintaan lintas asal berpotensi berbahaya dan dapat menyebabkan perubahan status jarak jauh 38 00:03:02,760 --> 00:03:04,800 permintaan juling server. 39 00:03:04,800 --> 00:03:08,670 Pemalsuan, atau CSIR adalah contoh serangan semacam itu. 40 00:03:09,360 --> 00:03:17,220 Sekarang kita sudah paham apa itu origin, mari kita coba memahami kebijakan same origin, same origin 41 00:03:17,220 --> 00:03:25,560 kebijakan atau S.O.P adalah kontrol keamanan tingkat browser yang menentukan bagaimana dokumen atau skrip dilayani 42 00:03:25,560 --> 00:03:29,460 satu asal dapat berinteraksi dengan sumber daya dari beberapa asal lainnya. 43 00:03:30,270 --> 00:03:37,080 Hal ini memastikan bahwa skrip yang berjalan di satu asal tidak dapat membaca data dari asal lain. 44 00:03:37,440 --> 00:03:45,450 Jadi dengan kebijakan asal yang sama, biasanya hak lintas asal diperbolehkan, namun hak lintas asal biasanya diperbolehkan 45 00:03:45,450 --> 00:03:46,050 tidak diperbolehkan. 46 00:03:46,680 --> 00:03:48,900 Bahkan jika menyangkut hak lintas asal usul. 47 00:03:48,900 --> 00:03:54,720 Ada beberapa batasan dalam kasus tertentu di mana permintaan tambahan akan dikirimkan oleh browser ke 48 00:03:54,720 --> 00:04:00,270 melakukan hal-hal seperti pemeriksaan pra-penerbangan, yang biasanya terjadi dalam permintaan XML HDB. 49 00:04:00,870 --> 00:04:06,330 Namun biasanya pengiriman formulir HTML diizinkan oleh kebijakan asal yang sama. 50 00:04:06,900 --> 00:04:13,260 Sekarang, dengan mengingat konsep-konsep ini, mari kita coba memahami bagaimana beberapa kerentanan yang umum terlihat 51 00:04:13,260 --> 00:04:18,810 seperti skrip juling dan pemalsuan permintaan situs biaya terkait dengan audit yang sama dalam kebijakan. 52 00:04:19,240 --> 00:04:21,780 Pertama mari kita bicara tentang skrip lintas situs. 53 00:04:22,380 --> 00:04:29,010 Seperti yang saya sebutkan sebelumnya, grup lintas asal biasanya tidak diperbolehkan saat Anda mencoba tampil lintas negara 54 00:04:29,010 --> 00:04:30,090 serangan skrip situs. 55 00:04:30,330 --> 00:04:36,540 Kami biasanya mencoba mengeksekusi JavaScript pada domain target dan mencoba membaca informasi sensitif 56 00:04:36,540 --> 00:04:37,410 seperti kue. 57 00:04:37,920 --> 00:04:44,730 Sekarang, hal ini biasanya tidak diizinkan oleh kebijakan asal yang sama, jadi Anda tidak dapat menyiapkan domain penyerang 58 00:04:45,030 --> 00:04:51,900 dan jalankan beberapa JavaScript di sana sedemikian rupa sehingga mengambil cookie dari situs web korban. 59 00:04:52,440 --> 00:04:58,920 Dan itulah alasan mengapa Anda harus menemukan cara untuk mengeksekusi JavaScript di situs korban. 60 00:04:59,830 --> 00:05:06,500 Itu skrip Crosseye, jadi karena ide kebijakan yang sama, skrip Crossfade tidak bisa dijalankan 61 00:05:06,680 --> 00:05:10,210 dengan mengeksekusi JavaScript pada domain yang dikendalikan penyerang. 62 00:05:10,900 --> 00:05:17,600 Nah, kalau soal CSR CSR, Rove biasanya dilakukan dengan menyerahkan formulir yang bisa dibuat 63 00:05:17,600 --> 00:05:18,920 beberapa perubahan keadaan. 64 00:05:18,920 --> 00:05:23,690 Di sisi server, Anda tidak mengharapkan untuk membaca respons apa pun dari server. 65 00:05:24,440 --> 00:05:27,770 Artinya kita hanya diwajibkan untuk melintasi wilayah kita saja. 66 00:05:27,770 --> 00:05:31,330 Benar, yang biasanya diperbolehkan oleh kebijakan Autogen yang sama. 67 00:05:31,700 --> 00:05:38,270 Jadi ketika Anda melakukan serangan pemalsuan permintaan semu, Anda dapat menghosting muatan Anda pada penyerang 68 00:05:38,270 --> 00:05:39,330 situs web yang dikendalikan. 69 00:05:39,860 --> 00:05:46,090 Nah begini keterkaitan Scripting dan CSR dengan melihat kebijakan Autogen. 70 00:05:46,280 --> 00:05:53,100 Jadi ide yang sama dalam kebijakan adalah landasan untuk memahami skrip Crosseye dan pemalsuan permintaan Crossfade 71 00:05:53,120 --> 00:05:53,690 serangan.